Package shipping system and method, including usage of historical analytic data

ABSTRACT

Embodiments provide methods, apparatus, systems, and computer-readable media associated with using historic analytic data to identify shipping options for a user to use when shipping a package. Historic analytic data may be received and maintained by a package shipment facilitation system. The analytics may then be used to generate business rules which may be applied to parameters for a package that is to be shipped. Through application of the business rules, one or more preferred shipping options may be identified. Business rules may be received after being manually-generated by a user, or may be automatically generated based at least in part on the maintained historic analytics. After a shipping option is chosen for the package, a shipping label may be printed for the package, and the package may be entered into a carrier&#39;s system for processing.

RELATED APPLICATIONS

This application is a continuation application of U.S. patentapplication Ser. No. 12/885,254, filed Sep. 17, 2010, entitled “PACKAGESHIPPING SYSTEM AND METHOD, INCLUDING USAGE OF HISTORICAL ANALYTICDATA,” which is a non provisional of U.S. Provisional Patent ApplicationNo. 61/243,924, filed Sep. 18, 2009, entitled “METHOD AND APPARATUS FORSHIPPING ARTICLE” and claims priority to the Ser. No. 12/885,254 and61/243,924 applications.

BACKGROUND

With the advance of the Internet and ecommerce, businesses andindividuals increasingly utilize carriers to ship packages they produce.Businesses and individuals may ship numerous packages each day, and mayship these packages to different destinations or under differentconstraints. For example, businesses and individuals may need to: shippackages overnight or by a specific time, ship to internationaldestinations, ship via ground transportation (such as for dangerousmaterials), require signature at delivery, ship to difficult or untesteddestination addresses, ship refrigerated or hazardous materials, andother requirements.

Numerous shipping options exist for these businesses and/or individualsto utilize for shipping their packages. Businesses and individuals maychoose from numerous regionally- or nationally-based package and lettercarriers. These individual carriers offer varying rates of service basedon destination, material, transportation requirements, and timerequirements. With all of these competing options, it can be difficultfor a business (more specifically, an employee of the business) or anindividual to choose a shipping option which best or close to bestsupports a particular or a group of shipping needs.

In existing systems, users are merely able to poll carriers to determineproposed shipping costs and proposed time-in-transit for a package.Beyond that, these systems seldom provide users with additional usefulinformation for the user to determine the “best” shipping option. Auser, knowing only the proposed cost of a particular shipping option,may be unsure about whether additional, unposted costs may presentthemselves during shipment. For example, if a package is not deliveredon time or in the right condition (e.g., melted, damaged), the carriermay be forced to refund money to the package's recipient. In anotherexample, a particular destination may present challenges, such astacked-on carrier surcharges for recipients who are frequently not athome or difficult to find. These costs may not be adequately representedin a carrier's posted fees to aid the user in carefully choosing thecarrier for their packages.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a block diagram of selected components of a packageshipment facilitation system using historic analytical data,

FIG. 2 illustrates a process for shipping a package using historicanalytical data,

FIG. 3 illustrates a process for receiving historic analytical shippingdata,

FIG. 4 illustrates an example of a display showing historic analyticalshipping data,

FIG. 5 illustrates a process for receiving a business rule to use whenchoosing a shipping option,

FIG. 6 illustrates an example of an interface for receiving a businessrule,

FIG. 7 illustrates an example of a display showing multiple shippingbusiness rules,

FIG. 8 illustrates a process for generating a business rule,

FIG. 9 illustrates a process for applying business rules to packageparameters to identify preferred shipping options, and

FIG. 10 illustrates an example computing device configured to practicevarious aspects of the earlier described methods, all ranged inaccordance with various embodiments of the present disclosure.

DETAILED DESCRIPTION

In the following detailed description, reference is made to theaccompanying drawings, which form a part hereof. In the drawings,similar symbols typically identify similar components, unless contextdictates otherwise. The illustrative embodiments described in thedetailed description, drawings, and claims are not meant to be limiting.Other embodiments may be utilized, and other changes may be made,without departing from the spirit or scope of the subject matterpresented herein. It will be readily understood that the aspects of thepresent disclosure, as generally described herein, and illustrated inthe Figures, can be arranged, substituted, combined, separated, anddesigned in a wide variety of different configurations, all of which areexplicitly contemplated herein.

The herein described subject matter sometimes illustrates differentcomponents or elements contained within, or connected with, differentother components or elements. It is to be understood that such depictedarchitectures are merely examples, and that in fact many otherarchitectures may be implemented which achieve the same functionality.In a conceptual sense, any arrangement of components to achieve the samefunctionality is effectively “associated” such that the desiredfunctionality is achieved. Hence, any two components herein combined toachieve a particular functionality may be seen as “associated with” eachother such that the desired functionality is achieved, irrespective ofarchitectures or intermedial components. Likewise, any two components soassociated may also be viewed as being “operably connected”, or“operably coupled”, to each other to achieve the desired functionality,and any two components capable of being so associated may also be viewedas being “operably couplable”, to each other to achieve the desiredfunctionality. Specific examples of operably couplable include but arenot limited to physically mateable and/or physically interactingcomponents and/or wirelessly interactable and/or wirelessly interactingcomponents and/or logically interacting and/or logically interactablecomponents.

Various aspects of the subject matter described herein are describedusing terms commonly employed by those skilled in the art to convey thesubstance of their work to others skilled in the art. However, it shouldbe apparent to those skilled in the art that alternate implementationsmay be practiced with only some of the described aspects. For purposesof explanation, specific numbers, materials, and configurations are setforth in order to provide a thorough understanding of the illustrativeexamples. However, it should be apparent to one skilled in the art thatalternate embodiments may be practiced without the specific details. Inother instances, well-known features are omitted or simplified in ordernot to obscure the illustrative embodiments.

With respect to the use of substantially any plural and/or singularterms herein, those having skill in the art may translate from theplural to the singular and/or from the singular to the plural as isappropriate to the context and/or application. The varioussingular/plural permutations may be expressly set forth herein for sakeof clarity.

It will be understood by those within the art that, in general, termsused herein, and especially in the appended claims (e.g., bodies of theappended claims) are generally intended as “open” terms (e.g., the term“including” should be interpreted as “including but not limited to,” theterm “having” should be interpreted as “having at least,” the term“includes” should be interpreted as “includes but is not limited to,”etc.). It will be further understood by those within the art that if aspecific number of an introduced claim recitation is intended, such anintent will be explicitly recited in the claim, and in the absence ofsuch recitation no such intent is present. For example, as an aid tounderstanding, the following appended claims may contain usage of theintroductory phrases “at least one” and “one or more” to introduce claimrecitations. However, the use of such phrases should not be construed toimply that the introduction of a claim recitation by the indefinitearticles “a” or “an” limits any particular claim containing suchintroduced claim recitation to inventions containing only one suchrecitation, even when the same claim includes the introductory phrases“one or more” or “at least one” and indefinite articles such as “a” or“an” (e.g., “a” and/or “an” should typically be interpreted to mean “atleast one” or “one or more”); the same holds true for the use ofdefinite articles used to introduce claim recitations. In addition, evenif a specific number of an introduced claim recitation is explicitlyrecited, those skilled in the art will recognize that such recitationshould typically be interpreted to mean at least the recited number(e.g., the bare recitation of “two recitations,” without othermodifiers, typically means at least two recitations, or two or morerecitations). Furthermore, in those instances where a conventionanalogous to “at least one of A, B, and e, etc.” is used, in generalsuch a construction is intended in the sense one having skill in the artwould understand the convention (e.g., “a system having at least one ofA, B, and C” would include but not be limited to systems that have Aalone, B alone, C alone, A and B together, A and e together, B and etogether, and/or A, B, and C together, etc.). In those instances where aconvention analogous to “at least one of A, B, or C, etc.” is used, ingeneral such a construction is intended in the sense one having skill inthe art would understand the convention (e.g., “a system having at leastone of A, B, or C” would include but not be limited to systems that haveA alone, B alone, C alone, A and B together, A and C together, B and Ctogether, and/or A, B, and C together, etc.). It will be furtherunderstood by those within the art that virtually any disjunctive wordand/or phrase presenting two or more alternative terms, whether in thedescription, claims, or drawings, should be understood to contemplatethe possibilities of including one of the terms, either of the terms, orboth terms. For example, the phrase “A or B” will be understood toinclude the possibilities of “A” or “B” or “A and B.”

Various operations may be described as multiple discrete operations inturn, in a manner that may be helpful in understanding embodiments;however, the order of description should not be construed to imply thatthese operations are order dependent. Also, embodiments may have feweroperations than described. A description of multiple discrete operationsshould not be construed to imply that all operations are necessary.Also, embodiments may have fewer operations than described. Adescription of multiple discrete operations should not be construed toimply that all operations are necessary.

The disclosure is drawn, inter alia, to techniques, methods,apparatuses, systems, articles of manufacture, and computer-readablemedia related to facilitating shipping of packages using historicanalytical shipping data.

Described embodiments include techniques, methods, apparatuses, systems,articles of manufacture, and non-transitory tangible computer-readablemedia which may be associated with using shipping business rules whichmay identify shipping options for a business or other user to use whenshipping a package. In various embodiments, historic analytic data (or“analytics”) may be received and maintained by a package shipmentfacilitation system. In some embodiments, these analytics may bereceived for the particular location of a business, or for selected orall locations of a business; in some embodiments, the analytics may bereceived for multiple businesses. The analytics may then be used, invarious embodiments, to generate business rules for a location of abusiness or for selected or all locations of a business. These businessrules may be applied to parameters for a package that is to be shipped.Through application of the business rules, one or more preferredshipping options may be identified. In various embodiments, businessrules may be received after being manually-generated by a user. Invarious embodiments, the business rules may be received and/or generatedbased at least in part on the stored historic analytics. After ashipping option is chosen for the package, a shipping label may beprinted for the package, and the package may be entered into a carrier'ssystem for processing.

Through the use of historic analytics, potential savings can beidentified. In various embodiments, these savings may include improvedefficiency, reduced costs, and enhanced quality and security of packageand freight delivery. Through the use of these analytics andidentification of shipping options, benefits to the business may beobtained other than those directly represented by a carrier's postedcost.

FIG. 1 illustrates a block diagram of selected components of a packageshipment facilitation system 100 according to various embodiments. Inthe illustrated example, the package shipment facilitation system 100communicates with a user 105 (typically of a business) to facilitate theuser in shipping packages (for the business). In various embodiments,the illustrated user 105 may be a user at a business, an individualacting on their own behalf, or may represent multiple users which act onbehalf of a business. In various embodiments, the user 105 may interactwith the package shipment facilitation system 100 though acomputer-based interface. For example, in one embodiment, the user mayinteract with the package shipment facilitation system 100 through adedicated application which communicates with the package shipmentfacilitation system 100, such as an application executing on the user'scomputer. In another embodiment, the user interacts with the packageshipment facilitation system 100 through a web-based interface, such asthrough a web page or through a toolbar installed on a web-browser. Inother embodiments, other users may also interact with the packageshipment facilitation system 100 in various embodiments, either at thesame business or at other sites. These users are not illustrated in FIG.1 for the sake of clear illustration.

In various embodiments, the package shipment facilitation system 100 mayalso interact with one or more carriers, illustrated in FIG. 1 ascarriers 180 a-180 n. In various embodiments, these carriers 180 a-180 nmay comprise local, regional, and/or nationally-based shippingcompanies. In various embodiments, the package shipment facilitationsystem 100 may interact with the carriers 180 a-180 n through knowntechniques, such as through application programming interfaces providedby one or more of the carriers 180 a-180 n. In other embodiments, thepackage shipment facilitation system 100 may communicate with thecarriers 180 a-180 n through web or other telecommunications interfaces.In various embodiments, the package shipment facilitation system 100communicates with the carriers 180 a-180 n to acquire information aboutshipping options, including transportation options offered by carriers(e.g., ground or air), time frames for shipments, insurance options,etc. In various embodiments, tracking, price, and/or cost informationmay also be obtained by the package shipment facilitation system 100from the carriers 180 a-180 n. In this way, historical shipping analyticdata may be obtained from the carriers 180 a-180 n in order tofacilitate package shipping, as described herein. In other embodiments,the package shipment facilitation system 100 may communicate with thecarriers 180 a-180 n to send package information and begin shipments.

In various embodiments, the package shipment facilitation system 100 maycomprise one or more modules, such as software, hardware, and/orfirmware modules to perform various shipping facilitation operations forthe package shipment facilitation system 100. In various embodiments,the modules may interact with the user 105 and/or with carriers 180a-180 n.

For example, in various embodiments, the package shipment facilitationsystem 100 may comprise an analytic data entry module 120. In variousembodiments, the analytic data entry module 120 may provide for one ormore users to input historic analytic data about past shipments. Inanother embodiment, the analytic data entry module 120 may be configuredto request and receive historic analytic data from the carriers 180a-180 n. In various embodiments the analytic data entry module, afterreceiving the historic analytic data, may store the historic analyticdata in the analytic history storage 150. In various embodiments, theanalytic history storage 150 may comprise various storage devices and/orsoftware storage modules, including, for example, a database and one ormore hard drive and/or solid-state storage devices. In variousembodiments, the historic analytic data may be displayed to a user usingthe illustrated analytics display module 175.

In various embodiments, the package shipment facilitation system 100also comprises a business rules storage 160, which stores one or morebusiness rules. In various embodiments, the business rules stored in thebusiness rules storage 160 may be applied to parameters for a package tobe shipped in order to identify one or more preferred shipping optionswhich may be used for that package. The business rules applicationmodule 130 may be used, in various embodiments, to perform applicationof one or more of the business rules to the parameters to identify theone or more preferred shipping options. Various embodiments of theparameters for a package may include, for example, destination address,time frame, delivery time, and/or transportation type. In variousembodiments, the parameters for a package may be entered by the userthrough an interface facilitated by the illustrated parameter entrymodule 165.

As will be described below, in various embodiments, the business rulesmay be received directly from the user, such as by the user creating oneor more business rules manually using the business rules generationmodule 140. In other embodiments, the business rules generation module140 may automatically generate one or more business rules, as will bedescribed herein. In various embodiments, the business rules generationmodule 140 may also allow the user to prioritize and/or editpreviously-entered business rules.

After identification of one or more preferred shipping options, thepackage shipment facilitation system 100 may, through its shipment labelgeneration module 110, generate one or more shipping labels for apackage. This shipping label may, in some embodiments, be printed on ashipping label printer 190, such as a printer attached to a computer ofthe user 105.

FIG. 2 illustrates an example process 200 for the package shipmentfacilitation system 100 to facilitate shipping a package using historicanalytical data. In various embodiments, the operations illustrated inprocess 200 may be combined, split into multiple separate operations, oromitted entirely. The process may begin at operation 210, where thepackage shipment facilitation system 100 may receive historic analyticdata regarding past shipments which have been made by the user or byother users and/or businesses. In one embodiment, operation 210 isperformed by analytic data entry module 120. Particular details ofoperation 210 are described below. Next, at operation 220, the packageshipment facilitation system 100 may receive parameters for a package.In one embodiment, the data may be received from a user shipping thepackage. As discussed herein, in various embodiments, the parameters mayinclude data such as, but not limited to, destination, time frame forshipment, insurance, whether the package should be signed for uponreceipt, insurance, preferred cost, etc.

At operation 230, the package shipment facilitation system 100 mayreceive business rules. In various embodiments, these business rules maybe particular to the user (or a location of a business) shipping thepackage, and/or may be generated or received based on other users(and/or other locations of the business and/or other businesses), ordynamically by data mining and extraction techniques on existing data.In various embodiments operation 230 may be performed in whole or inpart, by the business rules generation module 140. In variousembodiments, business rules may be received prior to receiving eitheranalytic data or parameters for a particular package. Particular detailsof operation 230 are described below.

At operation 240, the package shipment facilitation system 100 may applythe received business rules to the parameters received at operation 220to identify one or more preferred shipping options. In variousembodiments, the application may be performed through operation of thebusiness rules application module 130. Particular details of operation240 are described below. At operation 250, the package shipmentfacilitation system 100 may start a shipment of the package based on oneof the identified shipping options. In various embodiments, the packageshipment facilitation system 100 may print out a shipping label for theuser, send package information to a carrier, and/or begin financialtransactions to start the shipment. The process may then end.

FIG. 3 illustrates an example process 300 for the analytic data entrymodule 120 of the package shipment facilitation system 100 to receivehistoric analytic data. In some embodiments, process 300 may beperformed in one or more implementations of operation 210 of FIG. 2. Invarious embodiments, the operations illustrated in process 300 may becombined, split into multiple separate operations, or omitted entirely.The process may begin at operation 310, where the analytic data entrymodule 120 may receive historic analytic data from non-local sources. Inone embodiment, the analytic data entry module 120 may receive historicanalytic data from carriers, such as carriers 180 a-180 n. In anotherembodiment, the analytic data entry module 120 may receive historicanalytic data from multiple users, such as users representing variousbusinesses. In various embodiments, this data may be empirical data. Byaggregating this historic data, business rules may be created which aremore robust and which offer better efficiencies to users than if thebusiness rules were created entirely from locally-obtained analyticdata. At operation 320, the analytic data entry module 120 may receiveanalytic data related to the user (or the user's business). In oneembodiment, this may comprise receiving manually-entered data about pastshipments the user or business has made. In another embodiment, the usermay obtain shipping records, such as from carriers 180 a-180 n, andinput these into the analytic data entry module 120. In otherembodiments, historic analytic data related to the user or the user'sbusiness may be entered into the analytic data entry module 120 viaother methods. At operation 330, the analytic data entry module 120 maystore the received historic analytic data, such as by generating orupdating a database in the analytic history storage 150. The process maythen end.

FIG. 4 illustrates an example of a display 400 showing historicanalytical shipping data. The display may be presented to a user forreview to generate business rules, or simply to review historicaltrends. In various embodiments, the display is generated by theanalytics display module 175, such as by generating a web page or bysending information to software operating on the computer of the user105. In the embodiment illustrated, historic analytics are based on aparticular user's personal shipping history for a time period betweenFeb. 15, 2010 and Mar. 15, 2010. In the example, historic analytic dataabout shipping times is displayed under listing 410, titled “Averagetime in transit.” Example analytic 413 shows that, for this measuredtime period, FedEx Standard Overnight has had an average transit time of1 day for two packages. Furthermore, this represents a 100% on-time ratecompared to expected to transit times. The display also shows agraphical representation of the on-time rate at example 415. Bycontrast, example analytic 417 shows that for this user using theExpress IE shipping option during the measured time period, the userexperienced, a 3.43 day average transit time for 7 packages. The examplealso shows that only 57.14% of these packages were on time. In otherexamples, aggregate analytics may be displayed for a user by theanalytics display module 175, such as the aggregate transportation costsinformation 420 or the aggregate green ratings 430. In variousembodiments, historic analytic data such as those displayed, includingnominal prices, costs, unanticipated surcharges, time, and green-ratingdata, may be used to generate business rules, as described below.

FIG. 5 illustrates an example process 500 for the business rulesgeneration module 140 of the package shipment facilitation system 100 toreceive a business rule. Process 500 may be performed in one or moreimplementations of operation 230 of FIG. 2 to receive manually-createdbusiness rules from a user. The process may begin at operation 510,where the business rules generation module 140 may receive business ruleinputs. In various embodiments, business rule inputs may comprise, forexample, destination information, package information, time framerequirements, and/or other package information. At operation 520, thebusiness rules generation module 140 may receive an output shippingoption which is to be applied to a package that satisfies the businessrule inputs. In various embodiments, an indication for how many inputsare required for application of the business rule may be received. Forexample, in various embodiments, a received business rule may indicatethat, if one of a set of business rule inputs is true, a particularoutput shipping option should be selected. In another embodiment, areceived business rule may indicate that, only if every input out of aset of business rule inputs is true, then a particular output shippingoption should be selected. At operation 530, the business rulesgeneration module 140 may store the received business rule. In oneembodiment, the business rules generation module 140 may store thereceived business rule by storing the rule in a business rules databasein the business rules storage 160. The process may then end.

FIG. 6 illustrates an example of a display 600 showing oneimplementation of an interface for a user to manually enter businessrules, such as by using the process of FIG. 5. In various embodiments,the interface in the display 600 may be provided to a user by thebusiness rules generation module 140. At entry box 610, the user 105 mayenter a name so that the business rule may be identified. At selection620, the user may indicate whether the business rule should require thatevery or just one business rule input should be satisfied for thebusiness rule to apply. Then, at entry 630, a business rule input may beinput, illustrated in FIG. 6 as a “condition.” In the illustratedexample, the user may enter a destination zip code as a business ruleinput. Additionally, the user 105 may click on an “Add” link to addadditional business rule inputs. The example also shows a selection 640for a carrier, which represents the output shipping option which isindicated when a proper number of business rule inputs are reachedduring rule application. Finally, the example shows a selection 650 fora service to use with the carrier. Examples of services include nextday, second day, ground, etc. In various embodiments, the services whichare available for selection may depend on the carrier selection.

FIG. 7 illustrates an example of a display 700 showing oneimplementation of an interface for a user to review one or more businessrules, as well as for editing and/or prioritizing the one or morebusiness rules. In various embodiments, the interface in the display 700may be provided to a user by the business rules generation module 140.As FIG. 7 illustrates, the display 700 may show more than one businessrules, such as business rule example 710. In example 710, theexemplified business rule is applied to packages which: a) are to besent to Texas, and b) weigh less than 5 pounds. In the business rule ofexample 710, when both of these inputs are satisfied, the business ruleis applied to indicate that the package should be shipped via USPSParcel Post. In the business rule of example 720, the rule indicatesthat OnTrac Gold is the preferred shipping option for packages which areto be sent to zip code 98007. The display also shows example actionitems 730, which allow a user to edit any of the previously-generatedbusiness rules, and example items 750, which allow the rules to beselectively deleted. Also, by selecting action items 740, the user 105may move rules up or down in the list of business rules. In variousembodiments, business rules may be ordered so that a user can establishprecedence of one rule over another. Thus, in the example shown, thesystem will identify that a package sent to Washington should be shippedusing OnTrac CalTrac even if that package is going to 98007. The systemwill indicate the use of OnTrac CalTrac over OnTrac Gold (which is thepreferred carrier for 98007) because the former business rule is listedearlier in the list. In various embodiments, this order may create oneor more default business rules that are applied when no other,higher-ranked, rules are satisfied.

FIG. 8 illustrates an example process 800 for the business rulesgeneration module 140 of the package shipment facilitation system 100 toautomatically generate a business rule. In some embodiments, process 800may be performed in one or more implementations of operation 230 of FIG.2 to automatically generate business rules for a user or business,rather than relying on the user to manually create the rules. Theprocess may begin at operation 810, where the business rules generationmodule 140 may receive business rule inputs. In various embodiments,business rule inputs may comprise, for example, destination information,package information, time frame requirements, and/or other packageinformation. At operation 820, the business rules generation module 140may receive one or more indications of one or more analytics toconsider. In various embodiments the business rules generation module140 seeks values for analytics which are more desired by a user.

In various embodiments, the analytics may be preferred by a user (or theuser's business) to be higher or lower depending on the type of analyticbeing considered. Thus, in some embodiments, the business rulesgeneration module 140 may operate to increase those analytics for whicha higher value is desired by a user or business, such as on-timepercentage. In other embodiments, the business rules generation module140 may operate to decrease those analytics for which a lower value isdesired by the user or business, such as cost or distance traveled. Invarious embodiments, at operation 820, the business rules generationmodule 140 may receive one or more indications of whether higher orlower values are desired for the one or more received analytics. Inother embodiments, the business rules generation module 140 may beconfigured to recognize one or more of the analytics and to recognize,for those analytics, whether higher or lower values are desired.

At operation 825, the business rules generation module 140 determines,for an analytic, if a higher value is desired by a user or business. Ifnot, then at operation 830 the business rules generation module 140 mayseek out and set a shipping option for the business rule being generatedwhich produces lower values for that analytic than other shippingoptions. If, however, a higher value is desired, at operation 840 thebusiness rules generation module 140 may seek out and set a shippingoption for the business rule being generated which produces highervalues. In various embodiments, the business rules generation module 140may seek out a shipping option by simulating shipping using one or moreof the business rule inputs based on the historic analytical data storedin analytic history storage 150. In various embodiments, variousshipping options may be simulated and compared to each other to performthe selection of operations 830 and 840. Then, at operation 850, thebusiness rules generation module 140 identifies the output shippingoption which, in simulation, produced the most desired analytic outcome.At operation 860, the business rules generation module 140 may store thegenerated business rule. In one embodiment, the business rulesgeneration module 140 may store the generated business rule by storingthe rule in a business rules database in the business rules storage 160.The process may then end.

FIG. 9 illustrates an example process 900 for the business rulesapplication module 130 of the package shipment facilitation system 100to apply generated business rules for a package. In some embodiments,process 900 may be performed in one or more implementations of operation240 of FIG. 2. The process may begin at operation 910, where thebusiness rules application module 130 module may receive a sorted listof business rules. In one embodiment, the business rules applicationmodule 130 may receive this list by querying the business rules storage160. In some embodiments, the list may not be sorted. In some suchembodiments, the user may be queried to resolve conflicts amongst rules.

At operation 920, a loop may be begun starting with the first rule inthe list. At operation 925, the business rules application module 130may determine if the currently-considered rule can be applied to theparameters received for the package. In one embodiment, these parametersare received at operation 220 of FIG. 2. In various embodiments, thebusiness rules application module 130 may determine if the rule can beapplied by matching the business rule inputs identified in the rule tothe parameters for the package being shipped. If the rule applies, thenat operation 930, the rule may be applied and the output shippingoptions are added to a list of preferred options for the user. In oneembodiment, not illustrated, once a rule is applied, the process maystop and the shipping option may be presented to the user. However, inalternative embodiments, such as the one illustrated, at operation 940,the loop may be continued for the next business rule in the sorted list.Then, at operation 950, the list created by successive applications ofoperation 930 may be shown to the user 105. The user may then select ashipping option and may start shipment of the package, such as atoperation 250. The process of FIG. 9 may then end.

The techniques and apparatuses described herein may be implemented intoa system using suitable hardware and/or software to configure asdesired. FIG. 10 illustrates, for one embodiment, an example system 1000comprising one or more processor(s) 1004, system control logic 1008coupled to at least one of the processor(s) 1004, system memory 1012coupled to system control logic 1008, non-volatile memory (NVM)/storage1016 coupled to system control logic 1008, and one or morecommunications interface(s) 1020 coupled to system control logic 1008.

System control logic 1008 for one embodiment may include any suitableinterface controllers to provide for any suitable interface to at leastone of the processor(s) 1004 and/or to any suitable device or componentin communication with system control logic 1008.

System control logic 1008 for one embodiment may include one or morememory controller(s) to provide an interface to system memory 1012.System memory 1012 may be used to load and store data and/orinstructions, for example, for system 1000. System memory 1012 for oneembodiment may include any suitable volatile memory, such as suitabledynamic random access memory (DRAM), for example.

System control logic 1008 for one embodiment may include one or moreinput/output (I/O) controller(s) to provide an interface to NVM/storage1016 and communications interface(s) 1020.

NVM/storage 1016 may be used to store data and/or instructions, forexample. NVM/storage 1016 may include any suitable non-volatile memoryand/or non-transitory computer-readable media, such as flash memory, forexample, and/or may include any suitable non-volatile storage device(s),such as one or more hard disk drive(s) (HDD(s)), one or more solid-statedrive(s), one or more compact disc (CD) drive(s), and/or one or moredigital versatile disc (DVD) drive(s) for example.

The NVM/storage 1016 may include a storage resource physically part of adevice on which the system 1000 is installed or it may be accessible by,but not necessarily a part of, the device. For example, the NVM/storage1016 may be accessed over a network via the communications interface(s)1020.

System memory 1012 and NVM/storage 1016 may include, in particular,temporal and persistent copies of logic 1024. Logic 1024 may beconfigured to enable system 1000, in response to operation of the logic,to practice some or all aspects of the package shipment facilitationtechniques described earlier. In various embodiments, logic 1024 may beimplemented via programming instructions of any one of a number ofprogramming languages, including but not limited to C, C++, C#, HTML,XML, and so forth.

Communications interface(s) 1020 may provide an interface for system1000 to communicate over one or more network(s) and/or with any othersuitable device. Communications interface(s) 1020 may include anysuitable hardware and/or firmware. Communications interface(s) 1020 forone embodiment may include, for example, a network adapter, a wirelessnetwork adapter, a telephone modem, and/or a wireless modem. Forwireless communications, communications interface(s) 1020 for oneembodiment may use one or more antenna(s).

For one embodiment, at least one of the processor(s) 1004 may bepackaged together with logic for one or more controller(s) of systemcontrol logic 1008. For one embodiment, at least one of the processor(s)1004 may be packaged together with logic for one or more controllers ofsystem control logic 1008 to form a System in Package (SiP). For oneembodiment, at least one of the processor(s) 1004 may be integrated onthe same die with logic for one or more controller(s) of system controllogic 1008. For one embodiment, at least one of the processor(s) 1004may be integrated on the same die with logic for one or morecontroller(s) of system control logic 808 to form a System on Chip(SoC).

In various embodiments, system 1000 may have more or fewer components,and/or different architectures.

Although certain embodiments have been illustrated and described hereinfor purposes of description of the preferred embodiment, it will beappreciated by those of ordinary skill in the art that a wide variety ofalternate and/or equivalent embodiments or implementations calculated toachieve the same purposes may be substituted for the embodiments shownand described without departing from the scope of the disclosure. Thosewith skill in the art will readily appreciate that embodiments of thedisclosure may be implemented in a very wide variety of ways. Thisdisclosure is intended to cover any adaptations or variations of theembodiments discussed herein. Therefore, it is manifestly intended thatembodiments of the disclosure be limited only by the claims and theequivalents thereof.

1. A computer-implemented method for facilitating shipment of a package,the method comprising: receiving, by a computing device, one or moreparameters for shipment of the package; and based at least in part onthe one or more parameters and historical analytic data of one or moreavailable shipping options, identifying, at the computing device, one ormore preferred shipping options out of the one or more availableshipping options.
 2. The method of claim 1, further comprising:receiving, by the computing device, one or more business rules using theone or more historical analytic data; and wherein the business rules areconfigured such that, when the business rules are applied to theparameters, the business rules identify the one or more preferredshipping options.
 3. The method of claim 2, wherein receiving the one ormore business rules comprises: receiving, at the computing device,identification of one or more business rule parameter inputs for auser-defined business rule; and receiving, at the computing device, anoutput shipping option for the user-defined business rule.
 4. The methodof claim 2, wherein receiving the one or more business rules comprises:receiving, at the computing device, identification of one or morebusiness rule parameter inputs for a computer-generated business rule;and automatically identifying, by the computing device, an outputshipping option for the computer-generated business rule.
 5. The methodof claim 4, wherein: automatically identifying an output shipping optioncomprises automatically identifying, by the computing device, an outputshipping option which, when used with the one or more business ruleparameter inputs, results in higher values for one or more first typesof the historical analytic data as compared to other shipping options;and the first types of the historical analytic data are types for whicha user has identified that higher values are desired.
 6. The method ofclaim 4, wherein: automatically identifying an output shipping optioncomprises automatically identifying, by the computing device, an outputshipping option which, when used with the one or more business ruleparameter inputs, results in lower values for one or more second typesof the historical analytic data as compared to other shipping options;and the second types of the historical analytic data are types for whicha user has identified that lower values are desired.
 7. The method ofclaim 2, wherein receiving one or more business rules comprisesreceiving an identification of a default business rule.
 8. The method ofclaim 1, wherein shipping options comprise shipping via one or moredifferent carriers.
 9. The method of claim 1, wherein shipping optionscomprise different modes of transportation for the packages beingshipped.
 10. The method of claim 1, wherein parameters comprise adestination address or a delivery time.
 11. The method of claim 1,further comprising receiving the historical analytic data, by thecomputing device, including receiving empirical data taken from multipleusers.
 12. The method of claim 1, wherein receiving one or moreparameters for shipment of the package comprises receiving the one ormore parameters from a user shipping the package; and wherein the methodfurther comprises receiving, by the computing device, all or part of thehistorical analytic data from the user shipping the package.
 13. Themethod of claim 1, wherein historic analytic data comprises shippingprice or surcharges.
 14. The method of claim 1, further comprisingprinting, by the computing device, a shipping label for the package. 15.A system for facilitating shipment of a package, the system comprising:one or more computer processors; an analytic history storage coupled tothe one or more computer processors, the analytic history storageconfigured to contain historical analytic data for one or more availableshipping options; a business rules storage coupled to the one or morecomputer processors, wherein the business rules storage is configured tocontain one or more business rules based on the historical analytic datain the analytic history storage, and the business rules are configuredto identify one or more preferred shipping options out of the one ormore available shipping options based on one or more shippingparameters; and a business rules application module configured tocontrol the one or more processors, in response to operation by the oneor more processors, to: receive one or more parameters for shipment ofthe package; and apply the one or more business rules from the businessrules storage to the one or more parameters to identify one or morepreferred shipping options out of the one or more available shippingoptions.
 16. The system of claim 15, further comprising a business rulesgeneration module configured to control the one or more processors, inresponse to operation by the one or more processors, to generate the oneor more business rules based on the historical analytic data in theanalytic history storage.
 17. The system of claim 15, wherein historicalanalytic data comprises empirical data taken from multiple users andempirical data taken from a user from whom the parameters were received.18. An article of manufacture, comprising: a non-transitory tangiblecomputer-readable storage medium; and a plurality of computer-executableinstructions stored on the tangible computer-readable storage medium,wherein the computer-executable instructions, in response to executionby an apparatus, cause the apparatus to perform operations forfacilitating shipment of a package, the operations including: receivingone or more parameters for shipment of the package; receiving one ormore business rules based on historical analytic data; and applying theone or more business rules to the one or more parameters to identify oneor more preferred shipping options out of one or more available shippingoptions.
 19. The article of claim 18, wherein the operations furthercomprise generating the one or more business rules based on thehistorical analytic data.
 20. The article of claim 18, whereinhistorical analytic data comprises empirical data taken from multipleusers and empirical data taken from an entity with whom the preferencesare associated.